• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    The document describes computer-implemented systems and methods for sharing aeronautical data, comprising the steps of: maintaining a private blockchain, said blockchain involving a plurality of predefined parts; conditionally communicate aeronautical data, in response to a request from a party based on an exchange control mechanism, the data previously collected from aeronautical computers, e.g. FMS flight management systems on board aircraft. Developments describe in particular the use of: compensation, compensation and management mechanisms for access rights and / or user licenses; smart contracts; bidding or rating mechanisms for datasets; avionics and non-avionics data management; learning techniques performed on shared and consolidated data; management of derived block chains; of post-quantum encryption. Software aspects are described. Figure for the abstract: Fig. 1
    公开号:FR3090964A1
    申请号:FR1873873
    申请日:2018-12-21
    公开日:2020-06-26
    发明作者:François Coulmeau；Guillaume PABIA
    申请人:Thales SA；
    IPC主号:
    专利说明:

    Description
    Title of the invention: DISTRIBUTED REGISTERS FOR SHARING AERONAUTICAL DATA Field of the invention
    The document relates to the general technical field of information processing. In particular, the document describes systems and methods for sharing data in aeronautics, in particular using distributed databases. Prior art
    The sharing of data between industrial players in the same sector is always an issue, where cooperation and competition mix. Motivations to share data often come up against the desire to form a private corpus, for exclusive purposes. Regardless of the strategies of industrial players, basically, for the extraction of valuable data, it remains advantageous to accumulate large amounts of data (e.g. crossovers, correlations, learning, etc.).
    [0003] Certain technologies, in particular block chains (“blockchain” in English) or distributed registers (“distributed ledger” in English), if they are adapted appropriately, can redefine the challenges of data sharing and present opportunities as for new sharing methods.
    In the complex aeronautics ecosystem, flight computers produce a large amount of data, which can be of interest to a number of industrial players (aircraft manufacturers, equipment manufacturers, pilots and airlines, control authorities traffic, etc.). These same players also produce very large amounts of data, resulting in the creation of data silos which are generally not shared. Unless they are exploited in common, many opportunities are probably missed. Data can be enriched and value can be extracted from silos, in a wide variety of approaches.
    Small operators who have a reduced number of devices have a real interest in sharing data, because the algorithms for extracting data value require large volumes to be precise and reliable. However, the majority of aircraft operators fall into this category (few aircraft in operation), compared to the few large companies that may have sufficient data to analyze it.
    [0006] At the same time as the data is shared, it is important to be able to ensure that it comes from its source (authenticity) and that it is transmitted in accordance (integrity).
    Finally, it is important to find mechanisms tending towards a fair retribution of contributions, at least attractive enough to encourage sharing. In known approaches, these aspects are resolved in a non-technical manner, i.e. generally by contracts (for example with one or more intermediaries or brokers who specify and monetize the data sets that a supplier must produce for a customer).
    In terms of block chains (which can also be found under the terminology of DLT acronym for "Distributed Ledger Technology") applied to the specific context of aeronautics, everything remains to be done. The publications around the blockchain are almost exclusively in English and generally oriented towards Bitcoin and financial applications. The patent literature returns at the end of 2018 only two publications FR3062499 and FR3063406, which are interesting but are not relevant with regard to the technical problems raised.
    Patent EP3367137 entitled "Systems and methods of gathering and distributing critical weather event information" describes a system for sharing critical meteorological information between several aircraft. A ground center (intermediary) is responsible for managing requests between the different planes (customers and suppliers). This solution is satisfactory in certain situations but has limitations with regard to extended cooperation. For example, the examples described provide for the presence of an intermediary, which therefore adds to the already complex ecosystem of aeronautics. Furthermore, the transfer of information takes place only between planes; in particular, it does not rely on resources (however much more numerous) from the "open world" (i.e. beyond the regulatory framework, e.g. internet data). The type of database used is not explained. Only weather information is considered critical; flight optimization information is not considered, for example, but this information can be of great value.
    In avionics, the considerable amount of raw information generated by the computers on board an aircraft (for example) is the exclusive property of the supplier of this computer. Licenses can be put in place, generally between the supplier and the user (the manufacturer, the assembler, the customer, a regulatory authority), to allow the latter to use this information. This model has limitations and can change considerably.
    Summary of the invention
    The document describes systems and methods implemented by computer for sharing aeronautical data, comprising the steps of: maintaining a private blockchain, said blockchain involving a plurality of predefined parts; conditionally communicate aeronautical data, in response to a request from a party based on an exchange control mechanism, the data previously collected from aeronautical computers, e.g. FMS flight management systems on board aircraft. Developments describe in particular the use of: compensation, compensation and management mechanisms for access rights and / or user licenses; smart contracts; bidding or rating mechanisms for datasets; avionics and non-avionics data management; learning techniques performed on shared and consolidated data; management of derived block chains; of post-quantum encryption. Software aspects are described.
    In one embodiment, one or more block chains are used to store and share the data (thus ensuring their quality (eg timestamping, integrity, validation by consensus, etc.). Optionally, sharing of this data ( eg transactions) is managed (or permitted or controlled) by one or more smart contracts (eg access to data by users, rights management, etc.).
    Advantageously, the sharing and analysis of aeronautical information is improved. Raw or processed data, for example from aeronautical computers in a community of computer suppliers or users of these computers, are collected in order to extract enriched information of technical and / or business value.
    Advantageously, the authenticity and the integrity of the data handled are guaranteed due to the use of a block chain.
    Advantageously, the exchanges (or contributions) can be monitored, recorded and followed in a clear and transparent manner, so that the incentives to share are reinforced. “Unnecessary” data for a given party can be of great value for another party (for example a free “slot” pre-reserved for disembarking an airplane - and unused - can be bought by a third party company if the availability information is published).
    Advantageously, the sharing of information is encouraged, by construction, in addition to being secure.
    Advantageously, by implementing the exchange methods according to the invention, the use of intermediaries intervening in the management of data exchanges can be avoided or reduced. The concentration of data by a single actor (or intermediary), or a few parties (large companies for example), is generally sub-optimal because it does not allow a general processing, easily accessible to all suppliers and users, whatever their cut. It biases access to data, increases transaction costs, disperses rights, etc. The centralization of data can reduce the quantitative and / or qualitative collection of data for lack of reciprocity or interest, or even due to the complexity of access to data. As a result, the lessons or analyzes drawn from the data are of lower quality, to the detriment of end customers (e.g. user experience, aeronautical security, etc.). Conversely, the invention makes it possible to increase the capture of data, and consequently the quality of the analyzes which is derived therefrom ("analytics"). Sub-optimal exchanges, the invention allows fluid and transparent exchanges between actors, in which the incentives to share are reorganized, the shares being remunerated and the parties being noted in a transparent if not predictable manner, whatever their size in the industrial community.
    According to the invention, each stakeholder in the aeronautical blockchain is therefore free to focus on their job and to benefit from positive externalities created by others from their own, otherwise mutilable, data. A party will not have, or less, to obtain via a intermediary a set of transformed data which does not necessarily correspond to its specific needs (less control in the LA sense. As dependent on the algorithms which will have been developed by this intermediary ).
    In avionics, the application of artificial intelligence technologies (essentially machine learning) coupled with the massive deployment of connectivity between aircraft and / or the ground allows the massive use of all this data (so-called " Big Data ”) for advantageous and diverse purposes eg improvement of maintenance by analysis of a plurality of sources over time; emergence of value-added services for flight operations e.g. estimation of delays, overconsumption of fuel, optimization of trajectories, anticipation of flows, weather, etc .; improving flight safety and / or security, for example by analyzing flows and by early detection of latent anomalies or a priori that are difficult to predict; improving the passenger experience by providing targeted goods and services; improved mission management when many aircraft are engaged, such as drones, etc.
    New, complementary, additional, recent, or otherwise enriched aeronautical data can be manipulated.
    By integrating in a specific way (ie appropriate with regard to aeronautical business problems), the technologies relating to block chains and smart contracts, the methods and systems according to the invention ultimately make it possible to improve aviation security. This safety is fundamental in this industry. The existing aeronautical architectures are very closed (there are few links existing between systems, due to fear of data corruption, attacks, systemic risks, etc.); the proposed solution can significantly improve the technical management of cross-system data, by increasing the analysis surfaces (quantity of data) and the quality of the analyzes conducted.
    Description of the figures
    Other characteristics and advantages of the invention will become apparent with the aid of the following description and the figures of the appended drawings in which:
    Figure 1 illustrates the operation of a block chain according to the invention;
    FIG. 2 illustrates examples of steps of an embodiment of the method according to the invention.
    Detailed description of the invention
    The embodiments of the invention can use "block chains" to improve 1 "machine learning" performed on "Big data". These objects or expressions are defined and explained below.
    These objects have intrinsic properties, i.e. which are inherent to them and are independent of the context of use. However, the aeronautical constraints or requirements are numerous and complex. The constraints and trade-offs are difficult to identify clearly (invention of a problem) and justify or structure underlying variations in implementation, which otherwise might appear to be arbitrary.
    "Big data"
    The English expression "Big data" designates the collection and analysis of data, carried out on a massive scale. This concept is associated with characteristics of a technical nature which include: volume (eg large collections of data, even if they are redundant), variety (eg many different sources are used), velocity (eg the data is "fresh" ”Or constantly updated in changing or dynamic environments), attesting to a certain veracity (eg the weak signals which are drowned in the noise are not suppressed and can consequently be detected or amplified), to represent in fine a certain value (for example, from a technical and / or business point of view ie business).
    Machine learning
    Different types of automatic learning (or machine) are possible. Machine learning is an area of computing that uses statistical techniques to give computer systems the ability to learn with data (for example, to progressively improve the performance of a specific task), without being explicitly programmed for this purpose.
    Machine learning is advantageous for the detection and recognition of patterns or patterns or patterns. It is often easier to collect data (for example, data from a video game or board game) than to explicitly write the program that governs the game in question. In addition, neural networks (hardware realization of machine learning, or software emulation) can be reused to process new data. Machine learning can be performed on particularly large data, i.e. using as much data as possible (e.g. stability, convergence, weak signals, etc.). New data can be added continuously and learning can be refined.
    Different learning algorithms can be used, in combination with the characteristics according to the invention. The method may include one or more algorithms among the algorithms comprising: support vector machines or large margin separators (in English "Support Vector Machine", acronym SVM); "boosting" (classifiers); neural networks (in unsupervised learning); decision trees (Random Lorest), statistical methods such as the Gaussian mixture model; logistic regression; linear discriminant analysis; and genetic algorithms.
    Machine learning tasks are generally classified into two main categories, depending on whether there is a signal or learning inputs or feedback or outputs available ”.
    The expression "supervised learning" designates a situation in which examples of inputs and examples of outputs (real or desired) are presented to the computer. Learning then consists of identifying an interlacing of rules that matches the inputs to the outputs (these rules may or may not be understandable for humans).
    The expression "semi-supervised learning" designates a situation in which the computer receives only an incomplete set of data: for example, there is missing output data.
    The expression "reinforcement learning" consists of learning the actions to be taken, from experience, so as to optimize a quantitative reward over time. Through iterative experiences, a decisional behavior (called strategy or policy, which is a function associating in the current state the action to be executed) is determined to be optimal, in that it maximizes the sum of the rewards during time.
    The expression “unsupervised learning” (also called deep learning or deep learning) designates a situation in which no annotation exists (no wording, no description, etc.), leaving the learning algorithm alone to find one or more structures, between inputs and outputs. Unsupervised learning can be an objective in itself (discovery of structures hidden in the data) or a means of achieving an objective (functionality-based learning).
    According to the embodiments, the human contribution in the machine learning stages can vary. In some embodiments, machine learning is applied to machine learning itself (reflexive). The entire learning process can be automated, in particular by using several models and comparing the results produced by these models. In most cases, humans participate in machine learning ("Human in the loop"). The developers or curators are responsible for the maintenance of the clusters of data: ingestion of data, cleaning of the data, discovery of models etc.
    Machine learning can correspond to hardware architectures which can be emulated by computer (e.g. CPU-GPU), but sometimes not (circuits dedicated to learning may exist).
    Different learning algorithms can be used. The method may include one or more algorithms among the algorithms comprising: support vector machines or large margin separators (in English "Support Vector Machine", acronym SVM); "boosting" (classifiers); neural networks (in unsupervised learning); decision trees (Random Forest), statistical methods such as the Gaussian mixture model; logistic regression; linear discriminant analysis; and genetic algorithms.
    Materially, according to the embodiments, the method according to the invention can be implemented on or by one or more neural networks. A neural network according to the invention can be one or more neural networks chosen from neural networks comprising: a) an artificial neural network (in English "feedforward neural network"; b) an acyclic artificial neural network, eg a multilayer perceptron, thus distinguishing itself from recurrent neural networks; c) a forward propagation neural network; d) a Hopfield neural network (a discrete-time recurrent neural network model whose connection matrix is symmetrical and zero on the diagonal and where the dynamics are asynchronous, a single neuron being updated at each time unit ); e) a recurrent neural network (consisting of interconnected units interacting non-linearly and for which there is at least one cycle in the structure); f) a convolutional neural network (in English “CNN” or “ConvNet” for “Convolutional Neural Networks”, a type of feedforward acyclic artificial neural network, by multilayer stacking of perceptrons) or g) a generative antagonist network (in English “ generative adversarial networks »acronyms GANs, class of unsupervised learning algorithms)
    Distributed registers or block chains
    According to the definition given by Wikipedia, a block chain ("blockchain" in English) or a distributed register (DLT for "Distributed Ledger Technology" in English) is a database distributed and secured by crypto graphics techniques. The transactions exchanged are grouped into “blocks” at regular time intervals, securely by cryptography, which form a chain. After recording recent transactions, a new block is generated and analyzed. If the block is valid (distributed consensus), the block can be time stamped and added to the block chain. Each block is linked to the previous one with a hash key. Once added to the blockchain, a block can no longer be modified or deleted, which guarantees the authenticity and security of the network. Chaining uses hash functions and Merkle trees. A hash tree is made up of a set of interdependent checksums. Checksums are concatenated according to a tree structure. A hash tree allows you to verify the integrity of a data set without necessarily having all of the data at the time of verification. The records in a blockchain are protected against falsification or modification by storage nodes: falsifying a block requires falsifying the entire chain, so that the total cost becomes prohibitive and guarantees a level of confidence in the non-falsification of the entire blockchain. Transactions are visible throughout the network (except pruning called "pruning").
    Time is an important factor for block chains (notions of broadcasting, propagation, latency, etc.). The distributed consensus of all the nodes of the network can take a very variable time depending on the technologies used. It can be accelerated using various techniques, including "sidechains", which also increase storage capacity.
    In the context of distributed consensus, a blockchain can use a proof of work validation. From a mathematical point of view, a proof of work is "difficult to provide but easy to validate". Validation by evidence systems are generally asymmetrical: the calculation which is required in return for a service request is costly for the requester but remains easily verifiable by a third party. Different techniques can be used, including hashcash or a client-puzzle e.g. patent US7197639.
    The “minor” or “mining” nodes are entities whose role is to supply the network with computing power, to allow updating of the decentralized database. These minors can be compensated by the distribution of cryptographic tokens ("tokens"). Other clearing methods (in addition or by substitution) provide for commissions on transactions. "Miners" are not always necessary: in the case of private blockchains for example, the participants in the blockchain maintain the distributed database themselves.
    A blockchain can be public or private, or according to intermediate governance, which can use different barriers to entry (validation by proof of work). A “public” block chain works without a trusted third party (“trustless” model), generally with validation by complex proof of work (e.g. hashcash). A public blockchain generally does not define any other rule than that of the code constituted by the protocol and software technology which composes it. A “private” block chain includes nodes participating in the consensus which are defined in advance and then authenticated. Its operating rules can possibly be extrinsic.
    Blockchains can be or become programmable by the use of "smart contracts". Smart contracts are software or computer protocols that facilitate, verify and execute the negotiation or execution of a contract. They aim to emulate or approach the logic of contractual clauses (contract law). Smart contracts are not strictly equivalent to contractual agreements. They help make the breach of an agreement costly because they control a good through digital means. They can foresee - or not - the intervention of third parties to the contract to follow its execution (for example machines or "oracles" or oracle services. A smart contract is a software code which is stored and executed on / by a blockchain and is triggered by external data which allows it to modify other data, in the blockchain or elsewhere.
    The execution of a smart contract is predictable / predictable; at the very least the code and therefore the nature of the calculations or tests carried out by this code are known. The code of a smart contract is stored on or in the block chain; the execution of the smart contract is carried out during the validation of the blocks (the computing resources are distributed, which means that the execution of a smart contract is secure in itself: the code of the smart contract is replicated in several nodes of the architecture implementing the blockchain, being deterministic, the results of the different executions must be identical, therefore the code as well as the execution of the code are safe.
    As with any computer program or code, different programming languages are available, with different security and regulatory models (framework contract governing other contracts, cascading contracts, etc.). The forms taken by smart contracts can be diverse (e.g. services, agents, snippets, scripts, SOA, API, add-ons, plug-ins, extensions, DLC, etc.). Mathematical logic (decision making operating on data) can be that of classical, fuzzy, combinatorial, intuitionist, modal, propositional, partial, paraconsistent logic, etc. or a combination of these logics. The software can be coded in part or in whole in hard form (e.g. FPGA). A smart contract can be in whole or in part in open source ("open source") and / or in closed source ("closed source"). In the case of an open source, the code is auditable or verifiable by the parties or third parties. An intelligent contract can combine open source parties (e.g. auditable, verifiable, improvable, etc.) with closed parties (owners, secret, sensitive, etc.). A closed source can be a binary, possibly obfuscated or hardened. The cryptographic techniques can be diverse: symmetrical, asymmetrical, "post-quantum", "quantum-safe", with the use of "Quantum-Key-Distribution", etc.). A smart contract can be read by humans and / or machines ("human and / or machine readable").
    Embodiments of the invention are described below.
    In one embodiment, there is described a computer implemented method for sharing aeronautical data, comprising the steps of maintaining a private blockchain, said private blockchain involving a plurality of predefined parts; to conditionally communicate aeronautical data, in response to a request from one of the predefined parties, according to a predefined exchange control mechanism (eg coded in the blockchain, for example by one or more smart contracts) , the aeronautical data communicated being data previously collected from one or more onboard aeronautical computers (eg FMS) in one or more aircraft of predefined parts.
    In one embodiment, the exchange control mechanism includes access and / or communication of blockchain data in exchange for compensation or compensation, and the exchange control mechanism being determined by one or more smart contracts. A “retribution” is a sum of money paid in exchange for a job or a service. A “compensation” designates an operation by which purchases and sales are settled by means of reciprocal transfers, without movement of securities or money. Compensation of contributions (tending towards their balancing e.g. evaluated over predefined time periods) can be carried out in kind (e.g. sending data against data); fiat money is not necessarily used. Smart contracts can work in concert (eg by construction, intentionally, with systemic control mechanisms, according to deterministic decisions, etc.), but sometimes also be “in competition” (eg via service offers which are compared and then selected, "calls for tenders", probabilistic or random decisions, etc.).
    In one embodiment, the data of the block chain is at least partially encrypted and at least one intelligent contract determining access to the data, in particular by the management of encryption keys. According to the embodiments: all the data can be in the clear; all data can be encrypted and / or hidden; the data can be partially in clear (metadata) and encrypted for the rest.
    In one embodiment, the source code of the mechanism for controlling exchanges and / or one or more of the smart contracts being accessible, at least to the predefined parties. In other embodiments, the source codes are partially closed (binary, or obfuscated i.e. to discourage or prevent reverse engineering, or even hardened).
    In one embodiment, the exchange control mechanism comprising the determination of a financial amount and / or a reputation score associated with each of the predefined parties. Various reputation management mechanisms can be implemented, in particular by managing the “social graph” between actors. If it turns out that the same actors share their data with the same other actors, the blockchain can be split, for example automatically (the IT protocol can pre-empt human organizational decisions), transfer prices can be adjusted, etc.
    The management of data ownership can be partially or entirely managed by smart contracts. DRM mechanisms (Digital Rights Management) can manage transfers of ownership, license rights, exclusive or not, etc. For example, an exclusive license with a higher price paid will result in metadata indicating that the data is reserved for a specific use and control mechanisms (possibly with sanctions or penalties) may be implemented. The management of exclusive rights is not contradictory to the use of a block chain, insofar as the exchanges are transparent and the rules of the exchanges are clear and predefined.
    In one embodiment, the determination of the price of a data set being fixed and predefined, or being variable and determined dynamically, for example by auction, or by quotation with order book. Other financial mechanisms can be used (including the creation of derivative markets on data; certain players sensing the value of data of a certain type may associate it with options, etc.).
    In one embodiment, the data exchanges being controlled, for example capped, by the application of one or more thresholds or ranges of thresholds, in particular as a function of a data upload / download ratio. This approach is quantitative, and can be modulated by more qualitative approaches (where the quality of the shared data is assessed a priori and / or a posteriori, which can be the case if the downstream control mechanisms are sufficiently encompassing).
    In one embodiment, one or more intelligent contracts implement trading rules according to FRAND-type conditions, ie fair, reasonable and non-discriminatory prices. All the rules of competition law can generally be encoded in smart contracts, for example and including the detection and correction of an abuse of a dominant position.
    In one embodiment, the method further comprises a step consisting in displaying one or more scores associated with one or more predefined parts, a score testifying for example to a surplus or a deficit in uploading or downloading. or the number of cumulative uses of shared data sets.
    In one embodiment, the shared aeronautical data are avionic data and / or non-avionic data, coming from open sources.
    In one embodiment, the avionics data include for example flight parameters, trajectory data, flight plan data, air traffic data, flight instructions, ECM / EMU engine data, meteorological data, DFRD black box data, ATC / AOC / AAC data, NOTAM data and / or ACD perimeter data including data from FMS-certified computers, Autopilot or PA, flight controls or FCC , data from location systems or IRS / GNSS / ADC, data from surveillance systems ACAS-TCAS, TAWS-GPWS and radar, data from taxiing systems or AOF, data from radio communication systems RMS / RMP, company wireless communications data, AOC or ATC air traffic data, maintenance systems management data, warning, engine data, air conditioning systems data, landing gear management data, d data concerning the actuators, data concerning the electrical and / or hydraulic distribution in the aircraft. The information has demonstrated integrity (via the “DAL” levels from A to D). They are also checked for use, to guarantee the required level of robustness. These data are not exhaustive.
    The nature of the data implies technical characteristics in terms of reliability. An avionics system designates a reliable system (or one with guaranteed reliability). It is a system whose failure has consequences that exceed accepted or acceptable limits, and therefore feared. A failure can be characterized by the loss of the considered function, or by the production of erroneous data, with or without detection of an error. Depending on the level of criticality of the feared consequences, the probability of occurrence must be kept below an acceptability threshold. Thus, the more critical the consequence, the lower the probability of acceptable occurrence. For example, in aeronautics, a catastrophic event (multiple deaths) must have a probability of occurrence less than 10 Λ -9 per flight hour, while a major incident (reduction of safety margins and operational capacities, discomfort or minor injuries) should have a probability of occurrence less than 10 Λ -5 per hour flown. To ensure these objectives, the architecture of the avionics system (made more reliable) as well as the design of each component guarantee this probability of occurrence by guarantees of failure rate of each equipment (physical failures) and levels of verification (functional coverage and structural test) software. These requirements impose a significant design and verification effort, and impose a limitation in the complexity of the treatments implemented. Conversely, the failure of a system which is not reliable, or whose reliability is not guaranteed (“non-avionics” system) has consequences deemed tolerable, non-critical, or even without significant operational impact. The requirements on architecture, physical components or software processing are therefore lower, and allow more complex processing, and reduced development and verification effort compared to a reliable system. Generally, an avionics system is associated with a lower physical failure rate and a higher logical verification than those of a non-avionics type system.
    In one embodiment, the “non-avionics” data includes data from the AISD perimeter, such as data from electronic flight bags or EFB, data from cabin or IFE systems, or data from systems at ground.
    In one embodiment, the method further comprises one or more automatic learning steps carried out on the data accessible via the blockchain and / or one or more smart contracts.
    In one embodiment, the automatic learning is unsupervised. In one embodiment, machine learning is applied reflexively to different techniques of machine learning, in cooperation and / or in competition (the system learns to learn and chooses itself the most effective techniques).
    In one embodiment, machine learning comprises one or more algorithms selected from the algorithms comprising: support vector machines or large margin separators; classifiers; neural networks; decision trees and / or stages of statistical methods such as a Gaussian mixture model, logistic regression, linear discriminant analysis and / or genetic algorithms.
    In one embodiment, a smart contract includes a computer program stored in and / or executed by said block chain.
    There is described a system for sharing aeronautical data comprising: a private block chain maintained by a plurality of predefined and previously authenticated parts; said block chain being configured for the execution of one or more intelligent contracts; one or more aeronautical computers, for example a flight management system or FMS, associated directly with the block chain in read and / or write, and / or indirectly with the block chain via one or more smart contracts; said one or more intelligent contracts being configured to execute compensation mechanisms according to transactions relating to data sets exchanged between the predefined parties.
    In one embodiment, the compensation mechanism controls financial flows and / or reputation indicators and / or the data flows exchanged. The adjustment mechanisms may provide for various sanctions or penalties (e.g. suspension of account, ejection, etc.); in contrast, “rewards” or bonuses or gratuities or credits or points can be allocated. Human annotations can mark the data sets, ask questions, request additional data, etc. (all being traceable).
    In one embodiment, the system further comprises a centralized database and / or a so-called secondary block chain comprising aeronautical data, said data being referenced or indexed in the so-called main private block chain. More generally, N block chains can coexist, independently, or sometimes interdependent i.e. linked to each other.
    In one embodiment, the system further comprises: one or more neural networks, chosen from neural networks comprising: an artificial neural network; an acyclic artificial neural network; a recurrent neural network; a forward propagating neural network; a convolutional neural network; and / or a network of generative antagonistic neurons; said one or more neural networks being emulated in software by a block chain, primary or secondary, and / or by one or more intelligent contracts; and / or being physical circuits whose inputs and outputs are controllable by said block chains and / or by one or more intelligent contracts. Other types of hardware can be used ("A.I. accelerators", "A.I. chip", e.g. adaptive, regenerative networks, etc.
    In one embodiment, the encryption is obtained by postquantic cryptography. This type of encryption makes it possible to resist quantum attacks, if necessary. In fact, the data encrypted today cannot be decrypted even in the case of the advent of sufficiently powerful quantum computers. Aeronautical data is sensitive data (e.g. security logs) and therefore, it may be advantageous to use this type of cryptography. Homomorphic cryptography can be used (calculation e.g. learning on encrypted data).
    FIG. 1 illustrates an example of a distributed architecture according to the invention.
    Figure 1 shows 4 blocks of data BI to B4 (101, 102, 103, 104). The hash tree consists of a set of interdependent hash values. The leaves of the tree are the hash values of each of the initial data blocks (111, 112, 113, 114). In a Merkle tree (binary), these hash values are then concatenated two by two to be able to calculate a new parent hash (121, 122). So on to the top of the tree where we get a hash-top (131). To guarantee the integrity of a block with regard to all the data, it suffices to have the hash values of the brothers, the hash values of the uncles and the hash-vertex. In addition, only the hash-vertex (131) must be retrieved securely to guarantee the integrity of all the data represented by the tree. For example, if we want to verify the integrity of block B2, it is enough to have recovered the hash 0-0 (his brother 111), the hashl (his uncle 122) and the hash-summit (131).
    A data block can include one or more codes or programs or smart contracts 140.
    Concretely, a smart contract 140 can implement one or more mechanisms: (a) access to data or parts of data: -i) management of access rights and sharing of encryption keys (in the case asymmetric encryption the private key is secret and known only to the user or the public key can be known from a registry); hardware encryption mechanisms can be used (TPM or HSM, smart card, etc.); ii) subscription per unit of time (daily, weekly, monthly, yearly, etc.) and / or per volume of data (e.g. per MB bytes of downloaded data); credit or point systems can be used; b) payment; transactions can be settled in unit of account (cryptocurrency or fiat currency e.g. USD or EUR);
    The data blocks (101, 102, 103, 104) are produced and then consumed, i.e. accessed, read and / or write, by parties or companies (e.g. illustrated by 151, 152, 153).
    A party or company or consumer can be the aircraft manufacturer, an assembler, an equipment supplier, a customer or an airline, a maintenance company, a regulatory authority, etc.
    A party can be a “producer” of data and / or a “consumer” of data. A data consumer can be referred to as "customer" or "requester" or "receiver" or "buyer" later. A producer can be referred to as "transmitter" or "server" or "supplier" or "seller" later. The expression "and / or" underlines the fact that production and consumption can be successive or alternative, or even simultaneous. As each party can buy and / or sell, take a license and / or grant a license, assign or give or share its own data, it can also access the data shared by the other parties. Sharing data creates other data, some of which may have commercial or technical or other value.
    For example, the on-board computers 151 in an aircraft consume and produce an extremely large amount of data. Most of the exchanges remain internal to the aircraft, and are used for the overall operation of the aircraft. Certain data may become external, i.e. be extracted and stored or transmitted online, for various applications:
    - "DFDR - Digital Flight Data Recorder": designates the black box of the aircraft. Data from several computers is aggregated there to reconstruct an incident or accident history. The users of these data are generally state authorities for monitoring incidents / accidents (in Erance the "BEA" - Accident Investigation Office ". The provision of data to feed the DEDR results from a legal obligation. The dataset is very reduced for storage reasons.
    - "ECM - Engine Condition Monitoring": the aircraft engines are very complex, require very fine tuning to optimize them, and special monitoring to predict anomalies (predictive maintenance). For these reasons, engine suppliers (“engine manufacturers”) either install “EMU -Engine Monitoring Units” to concentrate and store information on the engines, and possibly transmit them to the ground by digital data link, in order to analyze them. This data can quickly exceed GB (Giga Octet) per flight. These data are not transmitted to third parties and are used by the engine manufacturer or maintenance teams.
    - "AOC - ATC Datalink": operational data can be sent by the aircraft's digital communication computers ("CMU - Communication Management Unit") to airlines (AOC - Airline Operation Communication, AAC - Airline Administrative Communication ) or to the air traffic control authorities (ATC -Air Traffic Control). These data are limited in quantity, relate to the position of the aircraft, its trajectory, but also environmental conditions from on-board sensors. The list of data is formalized in international standards (AEEC ARINC702 for example for AOC data, RTCA DO212 / 219 for ATC data). The provision of data results either from a legal (ATC) or contractual framework between the company on the one hand and the CMU supplier or the manufacturer on the other hand.
    These data, as well as a few others, nevertheless represent a very small part of the raw data generated by the on-board computers. Other data, internal or external, may be shared.
    As another example of producer / consumer of data, the air traffic control authorities 152 feature prominently. The data may relate to NOTAM notifications, various alerts, routing statistics or flight plans, etc.
    Finally, a wide variety of parties 153 can consume or produce useful data: meteorology, analysis services ("analytics"), etc.
    The illustration makes it possible to understand the different layers or levels involved in the methods or systems according to the invention:
    - a first layer of metadata or block chain 100; inheriting properties inherent in a block chain (e.g. integrity, tamper-proof, etc.); the blockchain 100 is essential, the other levels are optional.
    - a second data layer 210 called or referenced by the block chain 100 (encrypted in part or in whole); this data may also include metrics for uploading, downloading, usage, etc. which may determine scores or other quantifications (by means of logical decision circuits e.g. computers);
    - a third layer of coordination or regulation between actors (who play in turn the roles of producer P 201 or consumer C 202, reading and / or writing on the block chain 100. The agreements between participants in the block chain can be written contracts (excluding technical), or partially - or entirely transcribed via smart contracts of type 140;
    - an optional fourth layer 220 can regulate smart contracts (linked contracts, independent contracts, framework contract modifying other contracts downstream, or conversely upstream, multiple feedback loops between contracts, feedforward, etc.). Optionally, this block 220 can represent one or more validators (or "oracles", which can correspond to an independent human and / or machine validation i.e. algorithmically encoded).
    A large number of embodiments of the invention are possible. Some examples are described below, it being understood that minor variations should be replaced within the scope of protection sought.
    Public or private channels
    In one embodiment, the blockchain 100 of aeronautical data is public. In one embodiment, the aeronautical data block chain is private: each participant is previously approved (by contract or agreement 201-202) and technically has keys or authentication means.
    Secondary or derived block chains
    Addition or substitution, one or more secondary block chains (not shown) can be used. For example, a primary blockchain may contain metadata relating to aeronautical data (i.e. including hash values of the data), while a secondary chain may contain the data itself.
    Algorithmic encoding of exchanges
    To regulate free and undistorted competition, limits or other safeguards can be encoded in an algorithmic manner. For example, if it turns out that there is only one supplier for a category of data (eg fuel consumption), then automatic price or tariff adjustment mechanisms can be imposed by smart contracts. : “reasonable” prices may be applied, without access conditions (non-discrimination). Independent rating entities (“oracles”) approved by the participants in the blockchain can contribute to the scores and / or methods of regulating transactions.
    Various compensation mechanisms (or compensation or compensation) can be implemented. Different incentive models can be implemented. In some cases, the mechanisms can be static and predefined. In other cases, these mechanisms can be dynamic. In certain embodiments, the mechanisms may tend towards equal treatment between the participating actors (a priori) or “fair” rewards (noted and / or adapted a posteriori).
    Regulation of exchanges
    The exchanges can be regulated algorithmically, i.e. in a clear, impartial and predefined manner, e.g. determination and manipulation of the scores of the participants in the block chain.
    In one embodiment, each participant is associated with one or more scores, which can change over time (e.g. regular updates, after each transaction, etc.). In one embodiment, the scores of a part are summarized in a synthetic score (“rank A”, “rank AA”, etc.) can be a synthetic aggregator of a plurality of criteria (including the quantification of the quality of data sent measured for example by the number of uses by peers, the sums spent spent or received, etc.).
    In one embodiment, a node or participant in the block chain is associated with a synthetic score VS (acronym for Value Score), which governs access to exchanges (as producer and / or consumer of data ).
    In one embodiment, this VS score can be a function of i) the "value" of the information it produces VS_PROD and ii) the "value" of the information it consumes VS_CONS. The VS value can be expressed in the form of a score (encrypted), a symbol, value in a cryptocurrency, real currency (fiduciary), etc.
    The term “value” designates a quantification carried out according to predefined criteria, this quantification aiming to interpret the absolute and / or relative utility of the data shared by the participant. The utility can indeed be absolute (some performance data may be rare, or on the contrary public and of zero utility eg empty weight of the aircraft), but also relative (data of change of flight plan levels depending on ATC centers and fuel consumption can significantly help machine learning processes by multiplying trajectory envelopes, etc.). The extrinsic quantification of the relative value can be difficult or even impossible to establish (depending on the context of uncontrolled use and external to the object of the invention), however any quantification effort may not be in vain and low estimates may be established, in particular due to the structuring in the market place (the value of the price of a type of data can reflect its usefulness downstream).
    In one embodiment, a customer or consumer buys for an amount VS_MONEY the right to consume (eg credits) to be able to later consume data (which can be useful if he consumes more than he does product). Another party to the blockchain can transform its VS (Value Score) into real money (or cryptocurrency), e.g. for other uses outside the invention. His VS is then reduced by the amount VS_MONEY. The VS score of a blockchain party is therefore likely to change depending on the attractiveness of the data that this party produces and shares. Different quantification methods, possibly considered in combination, are possible. The criteria may include one or more elements including: the number of subscribers, the number of downloads and / or uploads of data packets ("datasets"), results of votes or ratings awarded by one or more consumers, the volume in gigabytes of shared data, etc.
    The values VS_PROD (value of the data produced) and VS_CONS (value of the data consumed) can be calculated in various ways, in particular in quantity (volume of data) and / or in quality (eg criticality of the computer or of the on-board function ), in relative value result of a confrontation offer / demand (eg quotation, order book consensus on a price, proposal, counter-offer, acceptance, refusal, negotiation, etc.), taking into account the history of use of the price at a given time according to predefined parameters, taking into account minimum and maximum prices, as determined for example by a logical decision circuit emulating ERAND access conditions (fair, reasonable and non-discriminatory) , etc. The values or methods of calculation can be entered or determined by a smart contract, which can be bipartite (agreement between two actors) or multipartite (agreement between N suppliers and M consumers).
    In one embodiment, the block chain can determine (for example in real time) the score of a party participating in the block chain. This score being entered in the block chain inherits its properties (non-falsifiable value, certain history).
    In other embodiments, various analysis or meta-analysis services can be determined: history and list of contributors, calculation of risks of injection of false (ie simply erroneous) or malicious (intentionally false) data. to weaken or distort automatic learning by third parties, etc.). The blockchain being transparent as to at least some data (descriptive metadata, transaction history, etc.), a potentially malicious part will be quickly determined as such and ejected from the core of trust between authenticated parties. Conversely, the transparency of the system, the governance of which is at least partly auditable, encourages the stakeholders to give up a certain sovereignty over the data, in return for access to third-party data and / or financial compensation.
    When a producer publishes one or more data sets in a base 210, by publishing the corresponding hash values in the block chain 100, the corresponding metadata are added in a block, which is time stamped. The block allows the identification of the source (successful authentication) and provides a guarantee as to the integrity of the deposited data (hash values). When a consumer retrieves a data set from the base 210 associated with the blockchain, the score of the producer is reassessed (eg addition of the determined sum if the block is validated, withdrawal of the sum if the data set is corrupted or false or empty or otherwise not valid) as well as its own score (of a value for example opposite to that credited to the producer, but various weights can be applied). This transaction including these credit / debit writes, identification data, etc. is written in the block chain. In this way, the parties appear either in surplus or in deficit in the provision of data. It may be that situations of permanent or intermittent deficits are acceptable (e.g. compensable by financial flows): the main thing is that the arbitrations are transparent and secure, i.e. traceable and non-falsifiable.
    [0106] Embodiments with smart contracts
    In one embodiment, the collaborative sharing module can rely on one or more "smart contracts", the contract allowing for example to ensure equal treatment (in value) between the stakeholders. Data is shared on a blockchain to ensure timestamping and immutability.
    In one embodiment, all of the data in the blocks is written in clear (e.g. access rights are protected). In one embodiment, part of the data is written in clear (some information is readable by everyone, other information with higher added value is protected for example by encryption). In one embodiment, the data of the blocks is encrypted (e.g. symmetrical, asymmetrical, etc.). In some cases the data in the blocks is hidden in addition to being encrypted (the existence of the data is hidden, which provides additional protection).
    In one embodiment, the data are stored in one or more shared databases, encrypted in whole or in part, after verification of their integrity and the authenticity of the producer.
    In one embodiment, the validation of the data produced is carried out by distributed consensus (eg use validated with a score of "relevance" by several consumers, measurement and monitoring of the rate of use, etc.) and / or by validation a peer participating in the blockchain recognized as reliable in the chain (technical or administrative qualification).
    In one embodiment, some information (such as the format and / or the summary of the content of the encrypted block is left in the clear in a storage space (in the chain or outside the chain), so that a interested consumer can know whether the block interests him or not.
    In one embodiment, the use that a consumer wishes to make of the data of a block is governed (directly or indirectly via rules) by a smart contract. In other words, a smart contract can include one or more DRM (Digital Rights Management) mechanisms that can govern the manipulation of data (e.g. rights to read, write, copy, publish, etc.).
    In one embodiment, an intelligent contract can read block data in clear and trigger one or more operations, for example if the customer or requestor or consumer is validly subscribed to the type of data of the block considered or if conditions predefined are satisfied.
    In certain embodiments, the rights to the block data can be conditional on contribution criteria (in particular the upload / download ratio or “seed / leech” ratio).
    In one embodiment, access to the data or the rights to this data can be governed conditionally (for example if the customer balance or Value Score is positive).
    If necessary, if the conditional access is granted (or if the predefined conditions are satisfied), the smart contract executed can issue a transaction or request for data recovery, which transaction will be inserted (among several others) in a new block. If the consensus distributed confirms the block comprising the transaction, an encryption key allowing the reading of the desired data can be sent to the client; who can read and use the desired data.
    [0117] Example of implementation of a smart contract
    In one embodiment, a supplier fills a database with new data. A smart “provision” contract detects new data and stores metadata in a blockchain (e.g. identification, date, issuer, score, hash of data content, etc.). The data is sold or made available free of charge (auction mechanisms, first come first served, DRM license mechanism specifying the number of uses, etc.). The price of the thing can be determined, according to various mechanisms (eg calculation of value intrinsic to the data for example according to one or more pre-established models, calculation of value by the creation of a market, eg quotation and order book, auctions, reverse auctions, etc.). If an agreement on the thing and on the price is found between the blockchain (via a smart contract) and a client, then a transaction can be carried out (data against data; data against payment in currency eg fiduciary, private, units of account, internal blockchain credits). A smart “consumption” contract can then be triggered, for example verifying various conditions or criteria (e.g. eligibility, buyer score, quantified reputation, access rights, balance, etc.). An intelligent data "provision" contract can then be triggered and communicate the data purchased or licensed to the customer. For example, information from one or more data blocks (e.g. addresses, decryption key, hash values of data content, etc.). The customer, once in possession of the desired data can use it (for example technically, e.g. to improve statistics, enrich or feed machine learning systems). The uses of the data may, in addition to the technical protection measures, be legally supervised (by contract); for example, the customer may have a contractual obligation to destroy copies of the data available to him after the expiration of a certain date; he may be prohibited by contract from disseminating the data accessed, etc.).
    In an alternative embodiment, a plurality of providers share data and store the hash values of the data, as well as information relating to the format of the data, in one or more block chains. After completion of a transaction, one or more smart contracts check the buyer's value score, indicate the position of the data in the shared database, as well as the data decryption keys.
    In an alternative embodiment, one or more contracts use escrow or fiduciary deposit mechanisms, etc. (in English "escrow payment" etc). In particular the data can be re-encrypted, etc.
    [0121] Direct embodiment, without smart contracts
    In an alternative embodiment, producers and or consumers can do without smart contracts, by reading and / or writing (direct) in the block chain. For example, a producer can receive a purchase order from a consumer and if the transaction is successful can communicate directly to the consumer. Therefore the blockchain does not contain the data itself but only the description of the data. This embodiment is advantageous in that the data replicated in the blockchain is significantly less voluminous.
    [0123] Other embodiments are described below.
    [0124] Subscription (s)
    In one embodiment, an aircraft can, for example in turn, publish information intended for the other members of the network or else “subscribe” (in English “subscribe”) to the network, for example via a smart contract, and receive information about it automatically. For example, an aircraft can share its weather information (for example non-regulatory, or conditions crossed locally), securely and honestly, with other aircraft (specifically owned by other airlines). Subscription methods can include push and / or pull, unsubscribe, etc. /
    Differential confidentiality
    Differential confidentiality designates a property of anonymization which can be reached via different mechanisms. Different mechanisms reduce the risk of identifying a part or confidential data, if possible by maximizing the relevance of the results of a given request. These mechanisms include k-anonymity, t-closeness, l-diversity or zero disclosure exchanges of knowledge. This last expression designates a secure protocol in which an entity named “proof supplier” mathematically proves to another entity that a proposition is true without revealing any information other than the veracity of the proposition. In some embodiments, sharing mechanisms without knowledge can be implemented ("zero-knowledge"). A fleet of aircraft from company A can thus communicate security logs (eg attempts at cyber attacks), with other flights or other airlines, without critical information being disclosed to an attacker who access data (eg beyond protection by encryption, obsolescence, validity intervals, criticality levels, etc.)
    Embodiments with external validation
    In one embodiment, an intermediary is added: a data validator (not shown). In a first production stage, a source decides to publish data in the block chain (directly or indirectly via the base 210). The data is sent with an identifier (which identifies the source sending the data) and a summary of the content (eg parameters, units, quantity, format, etc.) as well as the date of the data (eg creation, validity, etc) This set forms a “block” to be validated. The validation subsystem receives the data. Validation is carried out either by consensus or by an external and "trusted" validator: other suppliers or users check the integrity of the data (and optionally the authenticity of the sender). This can give rise to compensation (in VS) for the node or nodes that participated in the validation. It can be the consumer who checks the integrity of the block (hash). In one embodiment, the consumer can “note” (unilaterally) the attractiveness of the block received (his estimated interest for and by himself). In one embodiment, the score is given by the consumer. In one embodiment, the score is calculated by counting the number of downloads of the data set considered and / or by the number of interested consumers or actual buyers / licensees. If the data is declared as invalid then the blockchain is updated with a decrease in the VS_PROD by a certain amount for the producer, and an increase in the VS_PROD for the one who detected the anomaly. In one embodiment, if the data is considered valid / clean then a new block is created, which will contain the link to the data (eg addresses, keys), and an increase in VS_PROD by a certain amount for the node or the validation part.
    Embodiments with internal validation
    In certain embodiments, the validating third party is internalized: the verifications are carried out directly and automatically by one or more intelligent contracts. With each new entry in the database (and attempt to write a block), one or more smart contracts can perform various tasks, in particular a) checking whether the producer is declared (if it is a party to the consortium or block chain); b) modify the VS score of the source c) note or evaluate the data entered (directly or indirectly); possibly d) directly perform functional verifications on the data (for example, data from a model X aircraft can be correlated / cross-checked with other sources of information on the aircraft (eg public or private sources of the company, air traffic control) issued in real time and corresponding to the state of the aircraft (eg take-off time, current status eg in flight, on the ground, in cruise, current position ...).
    From the perspective of data consumption, a consumer subscribes or declares himself interested in recovering data (e.g. purchase order directly on the block chain or via a smart contract). The relevant smart contract can check if the buyer has sufficient balance (VS) to download the data. In an alternative embodiment, the purchased block is made available to one or more human validators and / or machines which perform this verification. If the transaction is valid, the dataset (for example encrypted) is transmitted to the buyer, who may for example have the possibility of checking its integrity (hash value retrieved from the blockchain). If the dataset is determined or deemed valid, decryption keys (stored in the blockchain) are retrieved by the smart contract and transmitted to the buyer. The transaction is then entered in the blockchain by the smart contract. In one embodiment, compensation and / or evaluation and / or compensation and / or validation mechanisms can be implemented if the data are determined to be valid (rating and / or reputation mechanism to identify or remunerate the most "useful" data transmitters (notion relating to one or more objectives that can be objectified and internalized). The requesting consumer ie initiator of the transaction can for example import the data obtained and cross it or integrate it with existing data with the aim of carrying out Big Data processing using artificial intelligence techniques (in particular machine learning).
    In aeronautical matters, the consumer can for example use the hours of arrival predicted at the waypoints, and the real hours of departure from the computer or FMS flight management system, for a set of planes which travel a line which he frequents, in order to draw correlations therefrom on the time of arrival at the airport as a function of events which he also recovers via this data sharing mechanism via a block chain (eg meteorology Air Data Unit type computers, ATC instructions from the CMU computer, trajectory actually followed by the aircraft from the GPS computers, Autopilot, traffic density information from the TCAS computers, etc.).
    Software and / or hardware implementation
    Materially, the embodiments of the invention can be carried out by computer. For example, a distributed architecture of the “cloud computing” type. Fully or partially distributed peer-to-peer servers (existence of centers) can interact. A blockchain is based on a decentralized architecture, which can be more or less distributed. A blockchain implementation does not preclude the existence of one or more privileged nodes, when it is a private cloud or a private blockchain. Access can be multiplatform (e.g. from EFB, WebApp, ground access, etc.). One or more EFBs can interact with one or more FMSs.
    In one embodiment, an aircraft is equipped with a module for communication and collaborative sharing of data from the computers on board the aircraft. This hardware module is in contact with various users and / or data providers. In one embodiment, the method is implemented by computer. The computer can be a rack or a tablet or an EFB or a software part integrated in the FMS, etc.
    The present invention can be implemented using hardware and / or software elements.
    It may be available as a computer program product on computer readable media. The support can be electronic, magnetic, optical, or electromagnetic.]
    权利要求:
    Claims (1)
    [1" id="c-fr-0001]
    Claims [Claim 1] Computer-implemented method for sharing aeronautical data, comprising the steps of:- maintain a private block chain, said private block chain involving a plurality of predefined parts;- conditionally communicate aeronautical data, in response to a request from one of the predefined parties, according to a predefined exchange control mechanism, the aeronautical data communicated being data previously collected from one or more aeronautical computers on board one or more aircraft of the predefined parts. [Claim 2] The method of claim 1, the exchange control mechanism, comprising accessing and / or communicating blockchain data in exchange for compensation or compensation, and the exchange control mechanism being determined by one or more smart contracts. [Claim 3] Method according to claim 2, the data of the blockchain being at least partially encrypted and at least one intelligent contract determining access to the data, in particular by the management of encryption keys. [Claim 4] Method according to any one of the preceding claims, the source code of the mechanism for controlling exchanges and / or one or more of the smart contracts being accessible, at least to the predefined parties. [Claim 5] Method according to any one of the preceding claims, the mechanism for controlling exchanges comprising the determination of a financial amount and / or of a reputation score associated with each of the predefined parties. [Claim 6] Method according to claim 5, the determination of the price of a data set being fixed and predefined, or being variable and determined dynamically, for example by auction, or by quotation with order book. [Claim 7] Method according to any one of the preceding claims, the data exchanges being controlled, for example capped, by application of one or more thresholds or ranges of thresholds, in particular as a function of a data upload / download ratio. [Claim 8] Method according to any one of the preceding claims, one or
    several smart contracts implementing trading rules according to FRAND-type conditions, ie fair, reasonable and non-discriminatory prices. [Claim 9] A method according to any one of the preceding claims, further comprising a step of displaying one or more scores associated with one or more predefined games, a score testifying for example to a surplus or a deficit of uploading or downloading of or the number of cumulative uses of shared data sets. [Claim 10] Method according to any one of the preceding claims, the aeronautical shared data being avionic data and / or non-avionic data originating from open sources. [Claim 11] Method according to claim 10, the avionics data comprising for example flight parameters, trajectory data, flight plan data, air traffic data, flight instructions, ECM / EMU engine data, meteorological data , DFRD black box data, ATC / AOC / AAC data, NOT AM data and / or ACD perimeter data including data from FMS certified computers, Autopilot or PA, flight or FCC commands, location system or IRS / GNSS / ADC data, ACAS-TCAS, TAWS-GPWS and radar surveillance data, taxiing or AOF data, RMS / RMP radio communication system data, company wireless communications, AOC or ATC air traffic data, maintenance systems management data, warning, engine data, air conditioning systems data, landing gear management data, data data concerning the actuators, data concerning the electrical and / or hydraulic distribution in the aircraft. [Claim 12] A method according to claim 11, the non-avionic data comprising data from the AISD perimeter, such as data from electronic flight bags or EFB, data from cabin or IFE systems, data from ground systems. [Claim 13] Method according to any one of the preceding claims, further comprising one or more automatic learning steps carried out on the data accessible via the blockchain and / or one or more intelligent contracts. [Claim 14] The method of claim 13, the machine learning being
    unsupervised, or being applied reflexively to different techniques of machine learning in cooperation and / or competition. [Claim 15] The method of claim 13, a machine learning comprising one or more algorithms selected from the algorithms comprising: carrier vector machines or large margin separators; classifiers; neural networks; decision trees and / or stages of statistical methods such as a Gaussian mixture model, logistic regression, linear discriminant analysis and / or genetic algorithms. [Claim 16] A method according to any of claims 2 to 15, a smart contract comprising a computer program stored in and / or executed by said block chain. [Claim 17] System for sharing aeronautical data comprising: - a private block chain maintained by a plurality of predefined and previously authenticated parts; said block chain being configured for the execution of one or more intelligent contracts; - one or more aeronautical computers, for example a flight management system or FMS, associated directly with the block chain in read and / or write, and / or indirectly with the block chain via one or more several smart contracts;- said one or more intelligent contracts being configured to execute compensation mechanisms according to transactions relating to data sets exchanged between the predefined parties. [Claim 18] The system of claim 17, the clearing mechanism controlling financial flows and / or reputation indicators and / or exchanged data flows. [Claim 19] The system of claim 18, further comprising a centralized database and / or a so-called secondary blockchain comprising aeronautical data, said data being referenced or indexed in the so-called primary private blockchain. [Claim 20] The system of any of claims 17 to 19, further comprising:- one or more neural networks, chosen from neural networks comprising: a network of artificial neurons; an acyclic artificial neural network; a recurrent neural network; a forward propagating neural network; a convolutional neural network; and / or a network of generative antagonistic neurons;
    - said one or more neural networks
    - being emulated in software by a block chain, main or secondary, and / or by one or more smart contracts; and / or - being physical circuits whose inputs and outputs are controllable by said block chains and / or by one or more intelligent contracts.
    类似技术:
    公开号 | 公开日 | 专利标题
    EP3671598A1|2020-06-24|Distributed registers for data sharing in aviation
    US10902320B2|2021-01-26|Architectures, systems and methods for program defined transaction system and decentralized cryptocurrency system
    CA3071976C|2021-07-06|Distributed ledger interaction systems and methods
    Swan2018|Blockchain for business: Next-generation enterprise artificial intelligence systems
    Mukhopadhyay2018|Ethereum Smart Contract Development: Build blockchain-based decentralized applications using solidity
    Basak et al.2017|Stream Analytics with Microsoft Azure: Real-time data processing for quick insights using Azure Stream Analytics
    Zutshi et al.2021|The value proposition of blockchain technologies and its impact on Digital Platforms
    EP3712798B1|2021-07-07|Distributed registers for managing the life cycle of data in aeronautics
    Mahankali2019|Blockchain: The Untold Story: From birth of Internet to future of Blockchain
    FR3095277A1|2020-10-23|DISTRIBUTED REGISTERS FOR THE MANAGEMENT OF METEOROLOGICAL DATA IN AERONAUTICS
    Zand et al.2021|Hands-On Smart Contract Development with Hyperledger Fabric V2
    Mohanty et al.2018|Decentralized autonomous organizations= blockchain+ AI+ IoT
    WO2021052853A1|2021-03-25|Management of flight plans by distributed registers
    FR3107777A1|2021-09-03|AVIONICS SOFTWARE AND DATABASE UPDATES
    Chen et al.2018|Cortex-AI on blockchain
    FR3107775A1|2021-09-03|MANIPULATION OF DATABASES BY DISTRIBUTED REGISTERS
    Bhagavan et al.2020|A primer on smart contracts and blockchains for smart cities
    FR3103040A1|2021-05-14|METHOD AND DEVICE FOR SECURE MANAGEMENT OF AN IMAGE BANK FOR AIRCRAFT LANDING ASSISTANCE
    US20220036323A1|2022-02-03|Electronic wallet allowing virtual currency expiration date
    US11188969B2|2021-11-30|Data-analysis-based validation of product review data and linking to supply chain record data
    US11017329B2|2021-05-25|Dampening token allocations based on non-organic subscriber behaviors
    US11276014B2|2022-03-15|Mint-and-burn blockchain-based feedback-communication protocol
    Karkeraa2020|Unlocking Blockchain on Azure
    US20210342836A1|2021-11-04|Systems and methods for controlling rights related to digital knowledge
    Rateb2021|Blockchain for the Internet of Vehicles: A Decentralized IoT Solution For Vehicles Communication and Payment using Ethereum
    同族专利:
    公开号 | 公开日
    CN111353179A|2020-06-30|
    FR3090964B1|2021-06-18|
    US20200204375A1|2020-06-25|
    EP3671598A1|2020-06-24|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US7197639B1|1999-02-05|2007-03-27|Rsa Security Inc.|Cryptographic countermeasures against connection depletion attacks|
    FR3062499A1|2017-02-02|2018-08-03|Ingenico Group|METHOD FOR REDUCING THE SIZE OF A BLOCKED CHAIN TYPE DATABASE, DEVICE AND PROGRAM THEREOF|
    EP3367137A2|2017-02-27|2018-08-29|Honeywell International Inc.|Systems and methods of gathering and distrubting critical weather event information|
    FR3063406A1|2017-02-28|2018-08-31|Airbus Helicopters|METHOD AND DEVICE FOR EXCHANGING INTEGRATED DATA|
    US11082226B2|2019-03-06|2021-08-03|Salesforce.Com, Inc.|Zero-knowledge identity verification in a distributed computing system|
    US11128465B2|2019-03-06|2021-09-21|Salesforce.Com, Inc.|Zero-knowledge identity verification in a distributed computing system|
    FR3107775B1|2020-02-27|2022-01-28|Thales Sa|MANIPULATIONS OF DATABASES BY DISTRIBUTED REGISTERS|
    法律状态:
    2019-11-28| PLFP| Fee payment|Year of fee payment: 2 |
    2020-06-26| PLSC| Publication of the preliminary search report|Effective date: 20200626 |
    2020-11-25| PLFP| Fee payment|Year of fee payment: 3 |
    2021-11-26| PLFP| Fee payment|Year of fee payment: 4 |
    优先权:
    申请号 | 申请日 | 专利标题
    FR1873873A|FR3090964B1|2018-12-21|2018-12-21|REGISTERS DISTRIBUTED FOR THE SHARING OF AERONAUTICAL DATA|FR1873873A| FR3090964B1|2018-12-21|2018-12-21|REGISTERS DISTRIBUTED FOR THE SHARING OF AERONAUTICAL DATA|
    EP19209210.4A| EP3671598A1|2018-12-21|2019-11-14|Distributed registers for data sharing in aviation|
    US16/691,077| US20200204375A1|2018-12-21|2019-11-21|Distributed ledgers for sharing data in the aeronautical field|
    CN201911322860.6A| CN111353179A|2018-12-21|2019-12-20|Distributed account book sharing aviation field data|
    [返回顶部]